The current implementation was made by taking Advanced Towing code as an example. Attaching the rope's end to a "Franta Can" and attaching that to the player's pelvis is a good way to accurately place the rope on the player, there may be better ways though.

At the moment, the rope handler doesn't generate a visible rope for GSAs or other units (shared radios), need to investigate that further.

How does the rope going to the pelvis look? Would it be better to have it go to the hand?
I think setObjectScale could be used to shink the franta can to make it functionally invisible.

Shrinking would still render the can whereas hiding doesn't (possibly deleting from, or even just skipping other unneeded data in, memory too), though.

Shrinking would still render the can whereas hiding doesn't (possibly deleting from, or even just skipping other unneeded data in, memory too), though.

Oh, yeah, hiding is fine too

How does the rope going to the pelvis look? Would it be better to have it go to the hand?

Depends, if there is an animation that puts the hand to the player's ear and maybe renders a phone handset like in ACRE Animations, sure. Otherwise I think it's best to keep the generic pelvis connection to symbolise that it's connected to the radio on the player's vest, just like the standard ACRE Gesture touches the player's vest to key any radio.

I've experimented further with player->player and GSA->player connections, the rope start object always has to be a transport, the smallest which classifies as such is a traffic cone with light.
Attaching that cone to a player works well to create the player->player connection for shared backpack radios, however it doesn't really work yet for GSA connections. For some reason when attachToing the cone to the GSA the rope's end won't connect to the player and instead dangle free. Another smaller issue is that the GSA+Mast center point is not in the model's center, so the rope start is kinda in midair, not visibily attached to the mast.

if there is an animation that puts the hand to the player's ear and maybe renders a phone handset

No phone, but I believe the sys_gestures component already in Acre animates the hand when speaking on a radio.

Sure, but you can't really keep the player's hand locked to his vest the entire time he's connected to the infantry phone.
That's why I think the pelvis is the best general location for the connector, it looks like this:

TBF, the cable needs to be tethered to something and then you'll need to route it through your uniform/vest to minimize getting tangled.

^ And being tethered in the middle it's quick to find the ends.

TBF, the cable needs to be tethered to something and then you'll need to route it through your uniform/vest to minimize getting tangled.

^ And being tethered in the middle it's quick to find the ends.

In both of these cases (infantry phone or using some one elses radio) you would not be routing the cable through your own gear, just holding the telephone on the end of the cable.

Going to the pelvis looks really ugly in that screenshot.

I'd appreciate a setting to either choose my own position or disable it.

Off
Pelvis
Hand
Etc.

I'd appreciate a setting to either choose my own position or disable it.

Off Pelvis Hand Etc.

Sure thing, a setting to disable is in the tasks.

How do you think it would look in the hand though when the left hand is on the rifle or other personal equipment? Would you also lock the player in the "hand on vest" animation the entire time he's using the infantry phone?

I think it would be cleaner to use some dedicated helper object instead of the Land_Can_V2_F. Also a cable looking rope model would be neat.

What sort of dedicated object do you suggest? Or do you mean creating a custom one that's hidden by default, for better performance?

Yes, I mean that the rope helper should be a dedicated class for that, preferably with a model that's just empty. Attaching a can feels dirty.

Would you also lock the player in the "hand on vest" animation the entire time he's using the infantry phone?

Honestly probably yeah, when you pick up the handset you're presumably using it to talk so I think it makes sense to keep the hand near the head.

It seems that spawning the rope on top of the interaction's position noticeably reduces the distance from which the "disconnect" interaction can later be seen and used. Exact cause unclear, but it's most likely the rope itself and not the helper object, since it also happens on infantry phone interaction (which doesn't use a helper).
The currently implemented workaround is lowering the rope start point, works pretty well for the infantry phone but more difficult on the GSA, because the spike is already at ground level, GSA+Mast unfortunately has the model's center point offset from the mast's center, so getting the rope to center in the mast regardless of model orientation will be trickier.

For some reason on both GSAs the rope doesn't attach to the player but dangles free, might be an issue where the rope collides with the GSA model.

I tested the man-to-man rope connection via debug console and it worked reliably, current implementation likely works too but I couldn't fully test it yet.

Finally got the GSA rope to work, attachTo-ing it would always lock the rope in place inside the GSA bounding box, probably because both GSAs are essentially buildings class-wise.
A different method of taking the helper object for the GSA, disabling its collisions with the GSA and moving it to the exact GSA location works nicely.
Also found a really small 10x10x10cm helper object PaperCar, fits much better than the Road Cone.

I just have a doubt regarding GSA disconnection.
There seems to be a GSA PFH on the client, sys_gsa/fnc_externalAntennaPFH.sqf, that checks for disconnection criteria, which will execute a local CBA Event to notify the player. There is also some similar CBA Server Event, I presume for handling multiple players trying to connect to the same GSA.
Rope handling is already global, so I presume they don't need to be integrated in any Server Events under sys_gsa.

I copied over the ACE Refueling hose model and config to make the connector rope black and look more like an actual wire, I presume that's ok since ACRE2 and ACE developments are somewhat related.
Unfortunately I lack the 3D design skills to make a custom and better fitting model.

There is an ongoing issue with a created rope reducing the effective range at which the disconnect interaction can be seen to <1m, happens whenever the rope start location is within ~50cm of the interaction's position.
Moving the start further than 20cm away from the interaction doesn't look good depending on which armoured vehicle you are connecting to, and looks downright ugly on the GSA (doesn't affect GSM though).

Looks like this now. Maybe a custom texture could be added to make the color less dark, but I think it's fine as is.

I wonder if the cable could be made breakable by gunfire & explosions, and/or by using the mouse wheel menu & ACE interact to cut it ?

^ Would increase realism, and depending on how you think about it, give engineers more reason to exist, or make life harder for engineers & mission devs & Zeuses.

Would be a neat feature for sure, though I guess it should come as part of a larger "radio damage" framework, possibly including what ACRE2 Radio Damage implements.

I wonder if the cable could be made breakable by gunfire & explosions, and/or by using the mouse wheel menu & ACE interact to cut it ?

^ Would increase realism, and depending on how you think about it, give engineers more reason to exist, or make life harder for engineers & mission devs & Zeuses.

That'd be nice for a field telephone system but I think it's overkill while there's only infantry phones.

Found an issue in MP where the helper object on a player was not deleted after using the infantry phone, presumably related to 2 people using the infantry phone simultaneously.

I figured out the cause, it's a bug that is also present in v2.12.0.1056.

The core issue is that more than 1 player can access the same infantry phone. Repro steps:

• Player A takes infantry phone;
• Player B takes infantry phone;
• Player A will now not be disconnected from the phone even when moving >20m from the vehicle. This caused the helper object for the ropes to not be destroyed when the rope breaks;

Haven't yet been able to verify how audio piping is affected by these steps.

Fixed the bug by checking the vehicle's (global) _unitInfantryPhone variable before generating a "take infantry phone" action.
This is almost complete, it just needs to handle passing of the infantry phone correctly, as well as a slight cleanup.

@Drofseh if you want to add the rope end selector feel free, I just think that would best be left to the modder of ACRE Animations to support, since that mod already has some decent handset models and animations in use right now.

just needs to handle passing of the infantry phone correctly

Done in 7f00b0b.

PaperCar for some reason appears to be overridden into an invalid object by one of the faction/map mods my community uses. Still need to isolate which one causes it but maybe it's best to create a custom helper object after all, to avoid any issues like this.

Most locality issues in GSA ropes are now completely resolved, I should have used CBA Events from the start given the complexity of that framework and how much of it is synced with remotes.

We found another issue, which is most likely in the base game.
While player A is connected to a GSA, if player B adds/removes the antenna's mast, the state of which player is connected to the GSA becomes desynced.
The most likely cause IMO is sys_gsa/fnc_handleMast.sqf not considering the previously connected unit for the reconnection process (after spawning the new spike variant), but only the unit who triggered the interaction.

This is pretty awesome. Have the latest issues from March been resolved as well?

Yes, it's been working pretty well so far during normal matches with our fork.
Passing of the infantry phone, as well as entering a vehicle while holding it needs some more in-depth testing. Same goes for external radio connections.

Just some minor cleanup and we can merge. 👍

I can't yet vouch for 100% functionality of the use cases mentioned above. Next week I should have the time for some in-depth tests.

Managed to get someone to test it with me today, found critical issues with infantry phone passing and the wire not connecting properly with a shared radio's operator.

Some locality weirdness appears to be the cause of the shared radio wire issues.
It turns out that the wire is actually connected properly on the machine of the one taking the headset/handset, but on the radio owner's machine, the wire just dangles from a helper object not attached to the owner.
This is especially odd because the connection between a player and GSA also uses 2 helper objects but is properly visualized globally.

Out of ideas on how to fix the rope locality issue for connections between a shared radio owner and user.
Basically creating rope between 2 helper objects, each attached to a player, will show the rope free-floating for the player the rope start point is attached to. Despite the helper objects themselves being synced properly.

Attempts to create the helpers with createVehicleLocal ran on all machines didn't work either, same visual result.

Given the apparent engine's limitations I'd be inclined to drop the external radio rope feature. They are only barely noticeable anyway, due to the close proximity required between owner and user.

That aside, the only issue to resolve is proper passing of the infantry phone and then this PR should be complete.

Done.